FIG. 1 schematically illustrates a representative node 2 in a communications system. In the illustrated example, the node 2 comprises a pair of parallel switch fabric cards 4, a pair of network-facing Input/Output (IO) cards 6, and a client facing IO card 8. Each of the network-facing IO cards 6 is connected to the network 10 via a respective interface 12, and to both of the parallel switch fabric cards 4. The client facing IO card 8 is connected to a client domain 14, via a respective interface 16, and is also connected to both of the parallel switch fabric cards 4.
In conventional communications nodes, one of the parallel switch fabric cards 4 is designated as a working card (indicated by “W” in FIG. 1), and carries subscriber traffic during normal operation. The other switch fabric card 4 is designated as a protection card (indicated by “P” in FIG. 1), and carries subscriber traffic during a failure of the working card 4. Similarly, one of the network facing IO cards 6 is designated as a working card (indicated by “W” in FIG. 1), and carries subscriber traffic during normal operation. The other network facing IO card 6 is designated as a protection card (indicated by “P” in FIG. 1), and carries subscriber traffic during a failure of a connection through the working IO card 6w, either due to failure of the working IO card itself or its interface to the network 10.
As is known in the art, each IO card 6,8 forwards subscriber traffic to either the working switch fabric card 4w or the protection switch fabric card 4p, based on the operational status of the working switch fabric card 4w. Additionally, the working and protection switch fabric cards 4w and 4p forward subscriber traffic to either the working IO card 6w or the protection IO card 6p, based on the operational status of connections mapped through the working IO card 6w. With this arrangement, the node provides 1-to-1 protection against failures of any of the switch fabric cards 4, IO cards 6 or interfaces 12. In some cases, a pair of parallel client-facing IO cards 8 may be provided, in a mirror image of the arrangement shown for the network-facing IO cards 6, which provides 1-to-1 protection for the entire path between the client domain 14 and the network 10.
As is well known in the art, other protection schemes can be implemented for any of the switch fabric cards 4, network-facing IO cards 6, and client facing IO cards 8 as desired. In general, any of these elements may be configured to operate in an m:n protection scheme, in which m protection elements are provided for n working elements. Thus, for example, in a node 2 having 16 network-facing IO cards 6, a 1:7 protection scheme (for the network-facing IO cards 6) may be implemented by designating a set of m=2 of the IO cards 6 as protection IO cards 6p, and the remaining n=14 IO cards 6 as working IO cards 6w. Similarly, m:n protection schemes may be implemented in respect of the switch fabric cards 4 and the client facing IO cards 8. The ratio of protection to working elements may be determined in accordance with any desired criteria, and may be the same, or different for each of the switch fabric cards 4, network-facing IO cards 6, and client facing IO cards 8. In some cases, the ratio of protection to working elements may be based on the probability of failure of a particular component. In alternative cases, the ratio may be based on the recovery time of the network, service level guarantees provided by the network service provider, or the capacity of the network to re-route traffic around a failed element.
A limitation of prior art protection schemes described above is that when the working elements are operating properly, the protection elements are idle. For example, in the embodiment of FIG. 1, when the working switch fabric card 4w is operating properly, the protection switch fabric card 4p is idle. In order to enable high speed failure recovery, the protection switch fabric card 4p must be maintained in a “hot standby” state, in which it is receiving power and its connection state synchronized with that of the working switch fabric card 4w, but no traffic is being routed through the card. In some cases, the protection mechanism is “exercised” by forcing a protection switch operation at regular intervals. This has the effect of periodically toggling the status of the working and protection switch fabric cards, so that each card carries traffic during alternating periods, and so ensures that the operational status of each card can be verified. However, only one of the switch fabric cards 4 actually carries traffic at any given time. In effect, therefore, the node 2 is always operating at 50% of its capacity. One reason for implementing protection schemes other than the 1:1 scheme illustrated in FIG. 1, is that it offers the possibility of improving the operating efficiency of the node. For example, in a node having three switch fabric cards 4, a 1:2 protection scheme would mean that, with both of the n=2 working switch cards operating properly, the node 2 would be operating at an efficiency of about 66%.
Various methods have been proposed for managing traffic flows through working and protection paths in a network, so as to increase utilization of the network capacity. Thus, for example, methods are known by which a network path designated as a protection path for one traffic flow may be used to carry network traffic while the working path is operating normally. Typically, pre-emption rules are used to determine what traffic in the “protection” path can be dropped to free up capacity for traffic switched from the (failed) working path. Normally, the pre-emption rules are based on Quality of Service (QoS) criteria assigned to each of the traffic flows in question.
However, these methods typically operate on layer-2 (or higher) and rely on packet forwarding rules that forward packets to appropriate output ports based on information in the packet header. Thus, for example, in some cases, the packet header may contain information relating to a Service Level Agreement (SLA) or a QoS guarantee. In other cases, the packet header may contain information of a network service with which the packet is associated. In any of these arrangements, the information may be used to control how the pre-emption rules affect forwarding of the packet. While such methods provide good performance for traffic flows within the network, they are not readily applicable to physical-layer switching within a node, because the physical-layer switching mechanisms do not have awareness of the content of the packet header.
Techniques for forwarding traffic trough a network node switch fabric that overcome limitations of the prior art remain highly desirable.